In recent years, video streaming has gained more attention from the communications industry, especially video streaming to wireless devices. One of the problems to cope with live video streaming to wireless devices is the variability of channel bandwidth. A media file (movie, song) is usually encoded to a certain bit rate. Therefore the transport of a media file between a server and a client requires a channel that has a minimum bandwidth capable of supporting the coding rate of the media. A higher encoding rate implies a better quality of the movie or song and translates into a larger size of the corresponding file and therefore a need for higher bandwidth.
Recently, there has been significant interest in transport methods based on the HTTP and TCP protocols. Such methods can be called “pull-based” methods because the transport of a presentation is controlled by the client device. Examples of such methods are Apple's HTTP Live Streaming and Microsoft's Smooth Streaming.
In pull-based transport methods, the presentation is segmented into multiple “chunks” of data, which are stored in a server. Individual chunks of data may represent the same portion of a presentation, but have differing encoding rates. The client device issues HTTP requests (GET) to the server for chunks of the presentation. The requested chunk is then transferred to the client device using the TCP/IP protocol. The chunks are grouped based on their encoding rate. Chunks in the same group have the same encoding rate and the same time duration of the media. Therefore, each group corresponds to a specific bandwidth. The client runs a download algorithm, which selects and downloads the next chunk of a presentation. The download algorithm tries to match the bandwidth required by the chunk's rate to the actual bandwidth offered by the communication channel.
In order to know how many and which chunks can be requested, each presentation has an associated “playlist”. The playlist is a text-file that contains information about how the presentation was segmented and the name and the location of each of the chunks. The playlists are organized in a hierarchical structure. There is a main playlist named “variant playlist”. The variant playlist specifies the names, the bandwidth and the location of other derived playlists. Each of these derived playlists store the URIs for the chunks that belong to the same coding rate. A derived playlist is also sometimes referred to as a simple playlist. Non-hierarchical structures are also possible for a playlist.
In certain implementations (e.g., a client device using the Android™ operating system), the client device is responsible for downloading these playlists. The download manager node downloads and parses the variant playlist and then the derived playlist to match the estimated bandwidth of the channel. When the estimation of the channel bandwidth changes, the download manager selects a different derived playlist and downloads the next file from that playlist. For live presentations, the derived playlist is dynamic in nature since the presentation is ongoing and since the server may not retain older portions of the presentation. In this case, the derived playlist is referred to as a sliding window playlist since the playlist contains URLs for a limited portion of the presentation near the current playback time.
At each moment, the download manager downloads the highest possible rate chunk to provide the best video quality while trying to avoid buffer starvation (which corresponds to a video freeze).
The bandwidth for video delivery to wireless devices can be expensive as more and more users are downloading and watching videos on their wireless devices. Simultaneous downloads to multiple wireless users in a cell, WLAN hot spot, or in private networks will necessitate cell splitting or network reconfigurations to accommodate the demand. Live or scheduled (pay per view) broadcasts to many users are examples of video content downloading that is increasing the demand on the available bandwidth. The expense affects both the infrastructure equipment requirements and the quality of the presentation that the user perceives. HTTP Adaptive streaming solutions such as Apple's HTTP Live Streaming (HLS) and Microsoft's Smooth Streaming (MSSS) are designed to dynamically match the quality of the presentation to the available bandwidth thereby improving the viewing experience, but have limited impact on reducing the bandwidth demand.
For example, a key component of a Passive Optical Network (PON) based on ITU G.984 (GPON), is the Optical Line Terminal (OLT) node. The OLT can be seen as an optical bridge between the PON and an IP network, as shown in FIG. 1. A GPON may have several OLT nodes and each OLT allows several subscribers, in typical cases up to 1800 subscribers, to access the IP network. As shown in FIG. 1, each OLT has an input IP port and up to P=56 output PON ports. In typical architectures, the input port of the OLT has a maximum data throughput of B0,max=6 Gbps and each output port of the OLT has a maximum data throughput of Bi,max=2.5 Gbps.
Consider now that, in the busy hour, a number “s” of devices per port are consuming a VOD or Live/Linear video streaming session, each requiring an average data throughput R. If all such devices use HTTP Live Streaming, such streaming sessions would be carried in TCP-based unicast streams and even if a Live/Linear content is being watched by many devices, each of them would be consuming R bits/s of capacity. Therefore, the number s of devices that can simultaneously receive a streaming session of R bits/s per port is given by:
      s    ≤          min      ⁡              (                                            B                              i                ,                max                                      R                    ,                                    B                              0                ,                max                                                    P              ·              R                                      )              ,and considering B0,max=6 Gbps, Bi,max=2.5 Gbps, P=56, R=6 Mbps (a high resolution video stream), it is easy to see that s must be equal or lower than 1000 and we see that the input port of the OLT is not able to support the capacity required if the PON has more than 1000 subscribers consuming a video streaming session during this busy hour. Note that, even if all s devices per port were all watching the same video streaming session, the OLT would not be able to support them if they access the video streaming session through HTTP Live Streaming (or any one of the other HTTP/TCP-based streaming protocols).
A common approach to alleviate bottlenecks in a network in which many devices are consuming the same content is to employ broadcast technologies, which are supported in an IP network by using multicast. There are many protocols in use today to support multicast transmissions in IP networks; namely the RTP and the UDP protocols.
The Real-time Transfer Protocol (RTP) is designed for end-to-end, real-time, transfer of multimedia data. RTP implementations are built on the User Datagram Protocol (UDP). RTP supports data transfer to multiple destinations through multicast. The ability to multicast to multiple users that are interested in live presentations can have a profound reduction on bandwidth demand since the presentations are sent once rather than multiple times. However, RTP/UDP is inherently unreliable since the protocol does not provide error recovery/retransmission mechanisms.
Another issue with multicast technologies is that, depending on the propagation conditions of individual users, a multicast transmission of a presentation may not allow all users with varying channel conditions to properly demodulate the received packets of data. No capability currently exists for multicast recipients to adapt to the wireless conditions.
Another problem is that HTTP Live Streaming servers do not employ multicast technologies; i.e., instead of using RTP and UDP, they use HTTP and TCP, which are inherently unicast technologies. Finally, while IP multicast can be supported in a Local Area Network (LAN), it may not be supported in a Wide Area Network (WAN). Therefore a need exists for a method and apparatus for distributing live video to multiple devices that reduces overall system bandwidth to users having differing bandwidth capabilities.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will further be appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. Those skilled in the art will further recognize that references to specific implementation embodiments such as “circuitry” may equally be accomplished via replacement with software instruction executions either on general purpose computing apparatus (e.g., CPU) or specialized processing apparatus (e.g., DSP). It will also be understood that the terms and expressions used herein have the ordinary technical meaning as is accorded to such terms and expressions by persons skilled in the technical field as set forth above except where different specific meanings have otherwise been set forth herein.